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Abstract. In this paper, we study the phenomenon that instruction 
sequences are split into fragments which somehow produce a joint be- 
haviour. In order to bring this phenomenon better into the picture, we 
formalize a simple mechanism by which several instruction sequence frag- 
ments can produce a joint behaviour. We also show that, even in the case 
of this simple mechanism, it is a non-trivial matter to explain by means 
of a translation into a single instruction sequence what takes place on 
execution of a collection of instruction sequence fragments. 
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1 Introduction 

With the work presented in this paper, we carry on a line of research with 
which a start was made in [4] . This line of research is concerned with sequential 
programs that take the form of instruction sequences. Its working hypothesis is 
that instruction sequence is a central notion of computer science, which merits 
investigation for its own sake. 

An instruction sequence is considered to produce on execution a behaviour 
to be controlled by some execution environment. This behaviour proceeds by 
performing steps in a sequential fashion. Each step performed actuates the pro- 
cessing of an instruction by the execution environment in question. A reply 
returned by this execution environment at completion of the processing of the 
instruction determines how the behaviour proceeds further. 

The following phenomenon presents itself: instruction sequences are split into 
fragments which somehow produce a joint behaviour. The objective of this paper 
is to bring this phenomenon better into the picture. To achieve this, we formalize 
a simple mechanism by which several instruction sequence fragments can produce 
a joint behaviour. We show that, even in the case of this simple mechanism, it is 
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a non-trivial matter to explain by means of a translation into a single instruction 
sequence what takes place on execution of a collection of instruction sequence 
fragments. 

The question is how a joint behaviour of the fragments in a collection of 
fragments is achieved. The view of this matter is that there can only be a single 
fragment being executed at any stage, but the fragment in question may make 
any fragment in the collection the one being executed by means of a special 
instruction for switching over execution to another fragment. This does not fit 
in very well with the conception that the collection of fragments constitutes a 
sequential program. To our knowledge, a theoretical understanding of this matter 
has not yet been developed. This has motivated us to take up this topic. 

The principal reason for splitting instruction sequences into fragments is 
that the execution environment at hand sets bounds to the size of instruction 
sequences. In the past, the phenomenon occurred explicitly in many software 
systems. At present, it often occurs rather implicitly, e.g. on execution of pro- 
grams written in contemporary object-oriented programming languages, such as 
Java [1] and C# [11], classes are loaded as they are needed. The mechanisms in 
question are improvements upon the simple mechanism considered in this paper, 
but they are also much more complicated. We believe that it is useful to consider 
the simple mechanism prior to the more complicated ones. 

The instruction sequences taken for fragments are called polyadic instruc- 
tion sequences in this paper. We introduce polyadic instruction sequences in the 
setting of program algebra [4] . The starting-point of program algebra is the per- 
ception of a program as a single-pass instruction sequence, i.e. a finite or infinite 
sequence of instructions of which each instruction is executed at most once and 
can be dropped after it has been executed or jumped over. This perception is 
simple, appealing, and links up with practice. 

The behaviours produced by instruction sequences on execution are modelled 
by threads as considered in basic thread algebra [4]. 1 We take the view that 
the possible joint behaviours produced by polyadic instruction sequences on 
execution are threads as considered in basic thread algebra as well. In a system 
that provides an execution environment for polyadic instruction sequences, a 
polyadic instruction sequence must be loaded in order to become the one being 
executed. Hence, making a polyadic instruction sequence the one being executed 
can be looked upon as loading it for execution. 

In [4], a hierarchy of program notations rooted in program algebra is pre- 
sented. Included in this hierarchy are very simple program notations which are 
close to existing assembly languages up to and including simple program nota- 
tions that support structured programming by offering a rendering of conditional 
and loop constructs. All of these program notations are referred to in this pa- 
per, but only one of them is actually used. That program notation is introduced 
under the name PGLD in [4]. 

1 In [4], basic thread algebra is introduced under the name basic polarized process 
algebra. 



2 



This paper is organized as follows. First, we review basic thread algebra 
and program algebra (Sections 2 and 3). After that, we give an overall picture 
of the hierarchy of program notations rooted in program algebra and present 
the program notation PGLD (Sections 4 and 5). Next, we introduce polyadic 
instruction sequences in the setting of program algebra, explain the possible 
joint behaviours of a collection of polyadic instruction sequences using basic 
thread algebra, and give an example of the use of polyadic instruction sequences 
(Sections 6 and 7). Following this, we extend basic thread algebra to allow for 
threads to make use of services and give a description of instruction register file 
services (Sections 8 and 9). After that, we show that, for each possible joint 
behaviour of a collection of polyadic instruction sequences, a single instruction 
sequence can be synthesized from the collection of polyadic instruction sequences 
that produces on execution essentially the behaviour in question by making use of 
an instruction register file service (Section 10). Finally, we make some concluding 
remarks (Section 11). 

In this paper, we only give brief summaries of program algebra and basic 
thread algebra. Comprehensive introductions, including examples, can be found 
in [4,14]. 

2 Basic Thread Algebra 

In this section, we review BTA (Basic Thread Algebra). BTA is a form of process 
algebra which is concerned with the behaviour that sequential programs produce 
on execution. Those behaviours are called threads. 

In BTA, it is assumed that fixed but arbitrary finite sets A and X with 
A fl X = and tau 6 I have been given. The members of A are called basic 
actions and the members of X are called internal actions. The members of AUX 
are referred to as actions. In previous work, we take in essence the singleton 
set {tau} for X. The generalization made here permits internal actions with 
differences relevant for analysis to be distinguished. 

The operational intuition is that a thread has an execution environment 
which processes each action performed by the thread. A thread performs actions 
in a sequential fashion. Upon each action performed, a reply from the execution 
environment of the thread determines how it proceeds. The possible replies are 
T and F. Performing an internal action, always leads to the reply T. 

Although BTA is one-sorted, we make this sort explicit. The reason for this 
is that we will extend BTA with an additional sort in Section 8. 

BTA has one sort: the sort T of threads. To build terms of sort T, BTA has 
the following constants and operators: 

— the inaction constant D : T; 

— the termination constant S : T; 

— for each a G AUX, the binary postconditional composition operator _ < a > _ : 
TxT^T. 
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Table 1. Axiom of BTA 



x <L>y = x <i>x Tl 



Table 2. Axioms for guarded recursion 

(X\E) = (t x \E) if X = t x € E RDP 
E X = if X G V(£) RSP 



We assume that there are infinitely many variables of sort T, including x,y, z. 
Terms of sort T are built as usual (see e.g. [15, 16]). We use infix notation for 
the postconditional composition operator. We introduce basic action prefixing 
as an abbreviation: a o p abbreviates p < a > p. 

The thread denoted by a closed term of the form p < a > q will first perform 
a, and then proceed as the thread denoted by p if the reply from the execution 
environment is T and proceed as the thread denoted by q if the reply from 
the execution environment is F. The threads denoted by D and S will become 
inactive and terminate successfully, respectively. A thread is inactive if it is 
neither capable of performing any action nor capable of terminating successfully. 

BTA has only one axiom. This axiom is given in Table 1. In this table, i 
stands for an arbitrary member of X. 

Notice that each closed BTA term denotes a thread that will become inactive 
or terminate after it has performed finitely many actions. Infinite threads can 
be described by guarded recursion. 

A guarded recursive specification over BTA is a set of recursion equations 
E = {X = tx | X E V"}, where V is a set of variables of sort T and each tx is a 
BTA term of the form D, S or t < a > t' with t and t' that contain only variables 
from V. We write V(E) for the set of all variables that occur in E. We are 
only interested in models of BTA in which guarded recursive specifications have 
unique solutions, such as the projective limit model of BTA presented in [2]. A 
thread that is the solution of a finite guarded recursive specification over BTA 
is called a finite-state thread. 

For each guarded recursive specification E and each X E V{E), we introduce 
a constant (X\E) of sort T standing for the unique solution of E for X. The 
axioms for these constants are given in Table 2. In this table, we write (tx\E) 
for tx with, for all Y E V(£ l ), all occurrences of Y in tx replaced by (Y\E). X, 
tx and E stand for an arbitrary variable of sort T, an arbitrary BTA term of 
sort T and an arbitrary guarded recursive specification over BTA, respectively. 
Side conditions are added to restrict what X, tx and E stand for. 

We will use the following abbreviation: o", where a E A Li I, abbreviates 
(X\{X = aoX}). 

We will write BTA+REC for BTA extended with the constants for solutions 
of guarded recursive specifications and axioms RDP and RSP. 

Closed terms of sort T from the language of BTA+REC that denote the 
same infinite thread cannot always be proved equal by means of the axioms of 
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Table 3. Approximation induction principle 



A„>0 M 21 ) = ^ 

n (x) = D 

7Tn + l(S) = S 
7T n + l(D) = D 

ir„+i(x <a>y) 



n 



= Tr n (x) <a>Tr n (y) P3 



(y) x = y 



AIP 



PO 



PI 



P2 



BTA+REC. We introduce AIP (Approximation Induction Principle) to remedy 
this. AIP is based on the view that two threads are identical if their approxima- 
tions up to any finite depth are identical. The approximation up to depth n of 
a thread is obtained by cutting it off after performing a sequence of actions of 
length n. In AIP, the approximation up to depth n is phrased in terms of the 
unary projection operator 7r n : T — > T. AIP and the axioms for the projection 
operators are given in Table 3. In this table, a stands for an arbitrary member 



We will write BTA+REC+AIP for BTA+REC extended with the projection 
operators and the axioms from Table 3. 

3 Program Algebra 

In this section, we review PGA (ProGram Algebra) . The perception of a program 
as a single-pass instruction sequence is the starting-point of PGA. 

In PGA, it is assumed that a fixed but arbitrary set 21 of basic instructions 
has been given. PGA has the following primitive instructions: 

— for each a € 21, a plain basic instruction a; 

— for each a € 21, a positive test instruction +a; 

— for each a € 21, a negative test instruction —a; 

— for each I e N, a forward jump instruction #1; 

— a termination instruction !. 

We write 3 for the set of all primitive instructions. 

The intuition is that the execution of a basic instruction a produces either T 
or F at its completion. In the case of a positive test instruction +a, a is executed 
and execution proceeds with the next primitive instruction if T is produced. 
Otherwise, the next primitive instruction is skipped and execution proceeds with 
the primitive instruction following the skipped one. If there is no next instruction 
to be executed, inaction occurs. In the case of a negative test instruction —a, 
the role of the value produced is reversed. In the case of a plain basic instruction 
a, execution always proceeds as if T is produced. The effect of a forward jump 
instruction #Z is that execution proceeds with the l-th next instruction. If I 
equals or the l-th next instruction does not exist, then #1 results in inaction. 
The effect of the termination instruction ! is that execution terminates. 

PGA has the following constants and operators: 



of A U 1. 
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Table 4. Axioms of PGA 

(x ; y) ; z = x ; (y ; z) PGA1 

(x n Y = a:" PGA2 

x" ; 2/ = x" PGA3 

(a ; y)" = x ■ (y ; xf_ PGA4 

Table 5. Defining equations for thread extraction operation of PGA 



|o| = a o D 


\#l\ = D 


\a ; x\ = a o \x\ 


|#0;x| = D 


\+a\ = a o D 


\#l;x\ = \x\ 


|+a ; ;c| = |x| <o> \#2;x\ 


\#l + 2;u\ = D 


—a =ooD 


|#I + 2;«;a;| = |#I + l;a;| 


|-o;a;| = \#2;x\ <a> \x\ 


|!|=S 




|!;x| = S 



- for each u G 3, an instruction constant u ; 

- the binary concatenation operator _ ; _ ; 

- the unary repetition operator _ w . 

We assume that there are infinitely many variables, including x,y, z. Terms are 
built as usual. We use infix notation for the concatenation operator and postfix 
notation for the repetition operator. 

A closed PGA term is considered to denote a non-empty, finite or periodic 
infinite sequence of primitive instructions. 2 Closed PGA terms arc considered 
equal if they denote the same instruction sequence. The axioms for instruction 
sequence equivalence are given in Table 4. In this table, n stands for an arbitrary 
natural number greater than 0. For each PGA term P, the term P n is defined by 
induction on n as follows: P 1 = P and P n+1 = P;P n . The equation = X;X" 
is derivable. Each closed PGA term is derivably equal to one of the form P or 
P ; Q w , where P and Q are closed PGA terms in which the repetition operator 
does not occur. 

Each closed PGA term P is considered to denote an instruction sequence 
of which the behaviour is a finite-state thread, called the thread produced by 
P. The set 21 of basic instructions is taken for the set A of basic actions. The 
thread extraction operation |_| determines, for each closed PGA term P, a finite 
guarded recursive specification over BTA that defines the thread produced by 
P. The thread extraction operation is defined by the equations given in Table 5 
(for a £ 21, I G N and u £ 3) and the rule that |#Z ; x\ = D if #Hs the beginning 
of an infinite chain of forward jumps. This rule is formalized in e.g. [8]. 

2 An infinite sequence is periodic if the set of all its subsequences is finite. 
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The behaviour of each closed PGA term, is a thread that is definable by a 
finite guarded recursive specification over BTA. The other way round, each finite 
guarded recursive specification over BTA in which no internal actions occur can 
be translated into a closed PGA term of which the behaviour is the solution of 
the finite guarded recursive specification concerned. 

Closed PGA terms are considered to denote programs and therefore they 
constitute an elementary program notation. Closed PGA terms are also called 
PGA programs. 

4 A Hierarchy of Program Notations Rooted in Program 
Algebra 

In [4], a hierarchy of program notations rooted in PGA is presented. The program 
notations that appear in this hierarchy are PGA, PGLA, PGLB, PGLC, PGLD, 
PGLDg, PGLE, and PGLS. The most interesting ones are PGLC, PGLD and 
PGLS. PGLC and PGLD are close to existing assembly languages. The main 
difference between them is that PGLC has relative jump instructions and PGLD 
has absolute jump instructions. PGLS supports structured programming by of- 
fering a rendering of conditional and loop constructs instead of (unstructured) 
jump instructions. 

For each of the program notations that appear in the hierarchy, except PGA, 
a function is given in [4] by means of which each program from that program 
notation is translated into a program from the first program notation lower in 
the hierarchy that produces the same behaviour on execution. These functions 
are called projections. Moreover, for each of the program notations that appear 
in the hierarchy, except PGLE and PGLS, a function is given in [4] by means 
of which each program from that program notation is translated into a program 
from the first program notation higher in the hierarchy that produces the same 
behaviour on execution. These functions are called embeddings. There does not 
exist a function by which each PGLE program is translated into a PGLS program 
that produces the same behaviour on execution because PGLS is strictly weaker 
than PGLE. The names of the projections and embeddings referred to above are 
given in Figure 1. 

The program notations, projections, and embeddings referred to above are 
defined in [4] . We refrain from giving all the definitions in question in this paper 
as well, because most details of the program notations, projections, and embed- 
dings do not matter here. The important point is that there exist a collection of 
well-defined program notations rooted in an elementary program notation with 
projections and embeddings between them. Only PGLD is actually used later 
on in this paper. Therefore, PGLD is reviewed below in Section 5. 

In Section 6, we will take special versions of the above-mentioned program no- 
tations for the ones that may be used for fragments. Moreover, we will make use 
of the projections pgla2pga and in addition the projections pglb2pga, pglc2pga, 
. . . defined in the obvious way by composition of projections given in [4]. In Sec- 
tion 10, we will make use of the embedding pglc2pgld and in addition the 
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PGLS 
pgls2pgle | 

PGLE 

pgle2pgldg | t pgldg2pgle 
PGLDg 

pgldg2pgld | t pgld2pgldg 
PGLD 

pgld2pglc | t pglc2pgld 
PGLC 

pglc2pglb | t pglb2pglc 
PGLB 

pglb2pgla | t pgla2pglb 
PGLA 

pgla2pga | t pga2pgla 

PGA 

Fig. 1. Hierarchy of program notations rooted in PGA 

embedding pga2pglc denned in the obvious way by composition of embeddings 
given in [4]. 

5 The Program Notation PGLD 

In this section, we review the program notation PGLD. This program notation 
is reviewed because it will be used later on in Sections 7 and 10. 

In PGLD, like in PGA, it is assumed that there is a fixed but arbitrary finite 
set 21 of basic instructions. Again, the intuition is that the execution of a basic 
instruction a produces either T or F at its completion. 

PGLD has the following primitive instructions: 

— for each a G 21, a plain basic instruction a; 

— for each a € 21, a positive test instruction +a; 

— for each a € 21, a negative test instruction —a; 

— for each I G N, an absolute jump instruction 

PGLD programs have the form u\;...;Uk, where u\, . . . ,u k are primitive in- 
structions of PGLD. 

The plain basic instructions, the positive test instructions, and the negative 
test instructions are as in PGA. The effect of an absolute jump instruction 
is that execution proceeds with the l-th instruction of the program concerned. 
If ##Z is itself the l-th instruction, then ##Z results in inaction. If / equals or 
I is greater than the length of the program, then termination occurs. 

The function pgld2pga from the set of all PGLD programs to the set of all 
PGA programs, which translates each PGLD program into a PGA program that 
produces the same behaviour on execution, can be defined directly as follows: 

Pgld2pga(wi ; . . . ; u k ) = (V>i(ui) ; . . . ; ipk{u k ) ;!;!)"> 
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where the auxiliary functions ipj from the set of all primitive instructions of 
PGLD to the set of all primitive instructions of PGA are defined as follows 



The idea is that each backward jump can be replaced by a forward jump if 
the entire program is repeated. To enforce termination of the program after 
execution of its last instruction if the last instruction is a plain basic instruction, 
a positive test instruction or a negative test instruction, ! ; ! is appended to 
^i(ui) ; ■ • ■ ; 4>k{uk)- 

6 Polyadic Instruction Sequences 

In this section, we formalize a simple mechanism by which several instruction 
sequence fragments can produce a joint behaviour. The instruction sequence 
fragments are viewed as instruction sequences that contain special instructions 
for switching over execution from one fragment to another. The instruction se- 
quences in question are called polyadic instruction sequences. 

It is assumed that a special version of PGLA, PGLB, PGLC, PGLD, PGLDg, 
PGLE or PGLS is used for each polyadic instruction sequence. Moreover, it is 
assumed that a collection of polyadic instruction sequences between which exe- 
cution can be switched takes the form of a sequence, called a polyadic instruction 
sequence vector, in which each polyadic instruction sequence is coupled with the 
program notation used for it. 

Our general view on the way of achieving a joint behaviour of the polyadic 
instruction sequences in a polyadic instruction sequence vector is as follows: 

— there can only be a single polyadic instruction sequence being executed at 
any stage; 

— the polyadic instruction sequence in question may make any polyadic in- 
struction sequence in the vector the one being executed; 

— making another polyadic instruction sequence the one being executed is ef- 
fected by executing a special instruction for switching over execution; 

— any polyadic instruction sequence can be taken for the one being executed 
initially. 

In addition to special instructions for switching over execution, polyadic in- 
struction sequences may contain two other kinds of special instructions: 

— special instructions for putting instructions into instruction registers; 

— special instructions of which the occurrences in a polyadic instruction se- 
quence are replaced by instructions contained in instruction registers on 
making the polyadic instruction sequence the one being executed. 



(1 <j< k): 



^■(##0 
^•(##0 
^•(##0 



! if I = V I > k , 

u if u is not a jump instruction . 



#1 - j \fj<l<k, 
#k + 2 - (j - I) if < I < j , 
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The special instructions of the latter kind serve as instruction place-holders. 
Their presence turns a polyadic instruction sequence into a parameterized in- 
struction sequence of which the parameters are filled in each time it is made the 
one being executed. This feature accounts for the use of the prefix polyadic. Its 
merit is primarily that it allows for execution to proceed in effect from different 
positions each time a polyadic instruction sequence is loaded for execution. An 
example of this is given in Section 7. 

We take the line that different program notations can be used for different 
polyadic instruction sequences in a polyadic instruction sequence vector. On 
making a polyadic instruction sequence in the vector the one being executed, it 
is considered to be translated into a PGA p program. 

PGAp is a variant of PGA in which the above-mentioned special instructions 
are incorporated. In PGA p , it is assumed that there is a fixed but arbitrary finite 
set 2l c of core basic instructions. In PGA p , a basic instruction is either a core 
basic instruction or a supplementary basic instruction. 

PGAp has the following core primitive instructions: 

— for each a e 2l c , a plain basic instruction a; 

— for each a <E 2t c , a positive test instruction +a; 

— for each a <E 2t c , a negative test instruction —a; 

— for each I e N, a forward jump instruction #1; 

— a termination instruction !. 

We write 3 C for the set of all core primitive instructions. The core primitive 
instructions of PGA p are the counterparts of the primitive instructions of PGA. 
PGAp has the following supplementary basic instructions: 

— for each i e N, a switch-over instruction 

— for each i eN and «e3 Cl a put instruction $put:i:u; 

— for each i e N, a get instruction $get:i. 

We write 2l s for the set of all supplementary basic instructions. In the presence 
of a polyadic instruction sequence vector, a switch-over instruction is the 

instruction for switching over execution to the i-th polyadic instruction sequence 
in the vector. A put instruction $put:i:w is the instruction for putting instruction 
u in the instruction register with number i. A get instruction $get:i is the in- 
struction of which each occurrence in a polyadic instruction sequence is replaced 
by the contents of the instruction register with number i on switching over exe- 
cution to that polyadic instruction sequence. If a get instruction is encountered 
in the polyadic instruction sequence being executed, inaction occurs. 

The supplementary basic instructions of PGA p can be viewed as built-in ba- 
sic instructions. However, as laid down below, supplementary basic instructions 
do not occur in positive or negative test instructions. Thus, the core primi- 
tive instructions and supplementary basic instructions make up the primitive 
instructions of PGA p . 

PGAp has the following constants and operators: 

— for each u e 3 C U 2l s , an instruction constant u ; 
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— the binary concatenation operator _ ; _ ; 

- the unary repetition operator _ w . 

The axioms of PGA p are the same as the axioms of PGA. 

Suppose that in PGA the restriction is dropped that 21 must be a finite set. 
Then PGA p can be viewed as the specialization of PGA obtained by taking the 
set 2l c U2l s for 21 and excluding terms in which basic instructions from 2t s occur in 
positive or negative test instructions. Henceforth, we actually drop the restriction 
that 21 must be a finite set. This simplifies the definitions of the different program 
notations that can be used for polyadic instruction sequences and also enables 
the use of the functions pgla2pga, pglb2pga, etcetera for translating programs 
in those program notations into PGA p programs. 

The different program notations that can be used for polyadic instruction 
sequences are PGLA p , PGLB p , PGLC P , PGLD p , PGLDg p , PGLE P , and PGLS p . 
The set of all PGLA p programs is the subset of the set of all PGLA programs, 
taking the set 2t c U2l s for 21, in which the basic instructions from 2l s do not occur 
in positive or negative test instructions. The other program notations are defined 
similarly. If the set 2l c U2l s is taken for 21, the function pgla2pga translates each 
PGLA p program into a PGA p program that produces the same behaviour on 
execution. Similar remarks apply to the other program notations. 

A polyadic instruction sequence is cither a PGLA p program, a PGLB p pro- 
gram, a PGLC p program, a PGLD p program, a PGLDg p program, a PGLE p 
program or a PGLS P program. 

A polyadic instruction sequence vector is a sequence of pairs consisting of a 
polyadic instruction sequence and a member of the set {A, B, C, D, Dg, E, S} of 
program notation indices. 

Let a be a polyadic instruction sequence vector, let Pi, . . . , P n and c\, . . . , c n 
be polyadic instruction sequences and program notation indices, respectively, 
such that a — ((Pi,ci)) ^ . . . ^ ((P„,c„)}, 3 and let i e [l,n]. Then we write 
pg(a,i) and pgn(a,i) for p and Cj, respectively. 

Let a be a polyadic instruction sequence vector of length n, and let i 6 [1, n}. 
Then program notation index pgn(a, i) indicates which program notation is used 
for polyadic instruction sequence pg(a,i). A stands for PGLA p , B stands for 
PGLB p , etcetera. The program notation used is made explicit because it can- 
not always be determined uniquely from the polyadic instruction sequence con- 
cerned, whereas the behaviour that this polyadic instruction sequence produces 
on execution may be different for each of the program notations in question. 

Below, we use special notation relating to the program notation indices. Let 
c be a program notation index. Then we write prj c for the projection pgla2pga 
if c = A, the projection pglb2pga if c = B, etcetera. 

The set of instruction registers that contain an instruction and the contents 
of each of those registers matter when a polyadic instruction sequence is made 

3 We write D* for the set of all finite sequences with elements from set D. We use 
the following notation for finite sequences: ( ) for the empty sequence, (d) for the 
sequence having d as sole element, a ^ a' for the concatenation of finite sequences 
a and a', and len(cr) for the length of finite sequence a. 
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the one being executed. That makes us introduce the notion of an instruction 
register file state and special notation relating to this notion. 

An instruction register file state is a function a : I — > 3 C , where / is a finite 
subset of N. 

Let p be a PGA p program and a be an instruction register file state. Then 
we write p[a] for p with, for all i e dom(a), all occurrences of $get:« in p replaced 
by a(i). 

Let i, n £ N be such that 1 < i < n, let a be a polyadic instruction sequence 
vector of length n, and let a be an instruction register file state. Then we write 
valid(a, i, a) to indicate that instructions of the form $get:i do not occur in 

P r i P gn( a ,t){P9{a,i))[°-]- 

An obvious choice of the thread extraction operation of PGA p is the thread 
extraction operation of PGA, taking the set 2l c U 2l s for 21, restricted to the 
set of closed terms of PGA p . This thread extraction operation is considered not 
to be the proper one, because it treats the supplementary basic instructions 
as arbitrary basic instructions and thus disregards the fixed effects that they 
produce on execution. Moreover, this thread extraction operation requires that 
in BTA the restriction is dropped that A must be a finite set. 

As regards the proper thread extraction for PGA p , the idea is that it yields, 
for each PGA p program P, a function that determines, for each polyadic instruc- 
tion sequence vector a, a finite guarded recursive specification over BTA that 
defines the thread that is the joint behaviour of P and the polyadic instruction 
sequences in a in the case where P is the polyadic instruction sequence being 
executed initially. Because this behaviour depends upon the set of instruction 
registers that contain an instruction and the contents of each of those registers, 
we need a thread extraction operation for each instruction register file state. 

In the thread extraction for PGA p , it is assumed that gl 6 I. The internal 
action gl (generate and load) represents the internal activity involved in switching 
over execution. The internal actions tau and gl are distinguished because tau is 
considered to represent a negligible internal activity, whereas gl is considered to 
represent a substantial internal activity. 

For each instruction register file state a, we introduce the thread extraction 
operation |_| CT . These thread extraction operations are defined by the equations 
given in Table 6 (for a € 21, I, i e N, u G 3 C U 2l s and v E 3 C ) and the rule that 

; X\a-(a) = D if #1 is the beginning of an infinite chain of forward jumps. 

We can couple nominal indices as labels with some of the polyadic instruction 
sequences in a polyadic instruction sequence vector. This would permit the use 
of alternative switch-over instructions with nominal indices instead of ordinal 
indices, like with the goto instructions from PGLDg. In the notational style 
of [3], the form of those alternative switch-over instructions would be 

7 Example 

To illustrate the mechanism formalized in Section 6, we consider in this section 
the splitting of a PGLD program P of 10000 instructions into two fragments. 
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Table 6. Defining equations for thread extraction operations of PGA P 

a| CT (a) — a oD 

a ■ x\ a (a) = a o |x| CT (a) 

+a| CT (a) — aoD 

+a ; x\ a (a) = \x\ a (a) <a> |#2 ; x\ a {a) 
— a|o-(a) = a o D 

— a ; x\ a (a) = |#2 ; x| CT (a) < a > |x| CT (a) 

#J|„(a) = D 

#0;x| CT (a) = D 

#1 ; x| CT (a) = |x| CT (a) 

#/ + 2;w| CT (a) = D 

#/ + 2;it;;r|, T (a) = |#Z + 1 ; x\ a (a) 

!|„(a) = S 

! ; x\ a (a) = S 

###i\<y(a) = gl° |pr/ p9 „ (a)j) (pff(a,i))[<7]| <7 (a) if 1 < i < n A valid(a, i, a) 
###i\a(a) = D if 1 < i < n A -ivalid(a, i, a) 

###i\ a (a) = S ifi = 0Vi>n 

###« ;a;|a(a) = gl ° |p^ MIi ( a ,i)(ps(a, if 1 < i < n A valid(a, i, a) 

; x| CT (a) = D if 1 < i < n A -ivalid(a, i, a) 

;x| CT (a) = S ifi = 0Vi>n 

$put:i:«|o-(Q) = tau o D 
$put:i:u ; x\ a (a) = tau o \x\ a(S[i ^ v] (a) 
$get:i| a (a) = D 
$get:i ; x\ a {a) = D 



We write u\{l) for the number of absolute jump instructions with i' > 

5000 from position 1 up to position I and 1*2 (0 for the number of absolute jump 
instructions with /' < 5000 from position 5001 up to position I. 

The polyadic instruction sequence P' corresponding to the first half of P is 
obtained from the first half of P as follows: 

— the instruction $get:l is prefixed to it; 

— each absolute jump instruction with I < 5000 is replaced by the absolute 
jump instructions ##?', where I' = I + + 1; 

— each absolute jump instruction with I > 5000 is replaced by the in- 
struction sequence $put:2:#/' ; ###2, where V = {I - 5000) + v 2 {l - 5000); 

and the polyadic instruction sequence P" corresponding to the second half of P 
is obtained from the second half of P as follows: 
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— the instruction $get:2 is prefixed to it; 

— each absolute jump instruction with I > 5000 is replaced by the absolute 
jump instructions ##/', where V = (/ - 5000) + u 2 (l - 5000) + 1; 

— each absolute jump instruction with I < 5000 is replaced by the in- 
struction sequence $put:l:#Z' ; ###1, where I' = I + 

Notice that the positions occurring in jump instructions are adapted to the 
prefixing of a get instruction to each half of P and the replacement of each jump 
instructions that gives rise to a jump into the other half of P by two instructions. 

For any instruction register file state a, we have that \P\ coincides with 
|$put:l:#l ; ###1| (7 (((P', D)) ^ ((P",D))) after the presence of the internal 
actions tau and gl in the latter behaviour has been concealed. In Section 8, we 
will introduce operators to conceal the presence of internal actions. 

In this section, we have illustrated by means of an example that splitting 
a program into fragments is relatively simple. In Section 10, we will show that 
synthesizing a program from a collection of fragments is fairly complicated. 

8 Threads-Services Interaction and Abstraction 

A thread may make use of services. That is, it may perform certain actions for 
the purpose of having itself affected by a service that takes them as commands 
to be processed. The processing of an action may involve a change of state of the 
service and at completion of the processing of the action the service returns a 
reply value to the thread. The reply value determines how the thread proceeds. 
In this section, we review the use operators, which are concerned with threads 
making such use of services. 4 We also introduce abstraction operators. They 
serve for concealment of the presence of internal actions, which arise among other 
things from the use operators. Both use operators and abstraction operators will 
be used later on in Section 10. 

It is assumed that a fixed but arbitrary finite set T of foci and a fixed but 
arbitrary finite set M. of methods have been given. Each focus plays the role of a 
name of a service provided by the execution environment that can be requested 
to process a command. Each method plays the role of a command proper. For 
the set A of basic actions, we take the set {f.m /ef,me M}. Performing a 
basic action f.m is taken as making a request to the service named / to process 
command m. 

A service H consists of 

— a set S of states; 

— an effect function eff : M x S — > S; 

— a yield function yld : Ai x S — > {T, F, B}; 

— an initial state sq € S; 

4 This version of the use mechanism was first introduced in [7]. In later papers, it is 
also called thread-service composition. 
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Table 7. Axioms for use operators 



S/ f H = S 






TSUI 


D/ f H = D 






TSU2 


(to x) If H = bo (x 


IfH) 




TSU3 


(x<g.m>y) // H - 


= (x/ f H)<g.m>{y/ f H) if / + g 




TSU4 


(x<f.m>y) IfH-. 


= tau o (x l f &H) if H(m) 


= T 


TSU5 


(x<f.mt>y) l f H . 




= F 


TSU6 


(x<f.m>y)/ f H 


= D if H(m) 


= B 


TSU7 



satisfying the following condition: 

Vm e M, s e S • (yld(m, s) = B => Vm' e • yld(m', eff(m, s)) = B) . 

The set £ contains the states in which the service may be, and the functions eff 
and 2/W give, for each method m and state s, the state and reply, respectively, 
that result from processing m in state s. By the condition imposed on services, 
once the service has returned B as reply, it keeps returning B as reply. 

Let H — (S 1 , eff , yld, sq) be a service and let m G M.. Then the derived service 
of H after processing m, written is the service (5, e/f , yW, eff(m, s )); and 

the rep^y of iJ after processing m, written H(m), is yld(m, sq). 

When a thread makes a request to the service to process m: 

— if H(m) ^ B, then the request is accepted, the reply is H(m), and the service 
proceeds as -£^H; 

— if H{m) = B, then the request is rejected and the service proceeds as a 
service that rejects any request. 

We introduce the sort S of services and, for each / £ J 7 , the binary use 
operator _//.:TxS^T. The axioms for these operators are given in Table 7. 
In this table, i stands for an arbitrary member of I, / and g stand for arbitrary 
foci from T, and m stands for an arbitrary method from A4. 

Intuitively, p // H is the thread that results from processing all basic actions 
performed by thread p that are of the form f.m by service H. When a basic 
action of the form f.m performed by thread p is processed by service iJ, it is 
turned into the internal action tau and postconditional composition is removed in 
favour of action prefixing on the basis of the reply value produced. This intuition 
is covered by axioms TSU5 and TSU6. Axioms TSU3 and TSU4 express that 
internal actions and basic actions of the form g.m with / ^ g are not processed. 
Axiom TSU7 expresses that inaction occurs when a basic action to be processed 
is not accepted. 

Let T stand for cither BTA, BTA+REC or BTA+REC+AIP. Then we will 
write T+TSU for T, taking the set {f.m /ef,m£ M} for A, extended with 
the use operators and the axioms from Table 7. 
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Table 8. Axioms for abstraction operators 



n(S) = S 
n(D) = D 

T L (bOx) = T L (x) 

t l (x <a>y) = t l (x) < a > T L (y) 
f\ n > n(n n (x)) = T L (7T n (y)) => r L {x) = r L (y) 



\fa^L TT4 



TT2 



TT3 



TT1 



TT5 



For each i £ I, wc introduce the unary abstraction operator t l : T — > T to 
conceal the presence of internal action i in the case where its presence does not 
matter. The axioms for the abstraction operators are given in Table 8. In this 
table, a stands for an arbitrary action from A U T. 

A main difference between the version of the use mechanism introduced here 
and the version of the use mechanism introduced in [10] is that the former version 
does not incorporate abstraction and the latter version incorporates abstraction. 

Let T stand for cither BTA, BTA+REC, BTA+REC+AIP, BTA+TSU, 
BTA+REC+TSU or BTA+REC+AIP+TSU. Then wc will write T+ABSTR 
for T extended with the abstraction operators and the axioms from Table 8. 

For each i G J, the equation r t (i w ) = D is derivable from the axioms of 
BTA+REC+AIP+ABSTR. 

9 Instruction Register File Services 

In this section, we describe services that make up register files with a finite 
set of registers that can contain instructions from a finite set of core primitive 
instructions. These services will be used in Section 10. 

It is assumed that a fixed but arbitrary set I C N such that I = [l,n] for 
some neN and a fixed but arbitrary finite set U C 3 C have been given. The set 
/ is considered to contain the positions of the registers in the instruction register 
file and the set U is considered to contain the instructions that can be put in 
those registers. 

We write IRFS for the set U/'c/ ^' — * U- The members of IRFS are consid- 
ered to be the possible instruction register file states. It is assumed that a fixed 
but arbitrary bijection 9 : IRFS — > [1, c&rd{IRFS)\ has been given. 

The instruction register file services accept the following methods: 

— for each i £ I and u G U, a register put method put:i:u; 

— for each j G rng(6>), a register file test method eq:j. 

We write Mm for the set {put:z:u \ ielAueU}U {eq:j \ j G rng(#)}. 
It is assumed that Ai n f C Ai. 

The methods accepted by instruction register file services can be explained 
as follows: 

— put:i:u : the contents of register i becomes instruction u and the reply is T; 
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- eq:j : if the state of the instruction register file equals 6 then nothing 

changes and the reply is T; otherwise nothing changes and the reply is F. 

Let s £ IRFSlill}, where | ^ IRFS. Then the instruction register file service 
with initial state s, written I1ZF S , is the service (IRFS, eff, yld, s), where the 
functions eff and yld are defined as follows (a G IRFS U {t}) ;5 

eff (put:i:w, er) — a © [i i— > u] , yld(put:i:n, a) = T , 
e#(eq:i,c7) = <r , yld(eq:j,a) = T if 0(a) = j , 

yld(eq:j,a) = F if 0(ct) 7^ j , 
eff(m, a) — ] if m ^ A4i r f , yld(m, a) = B if m ^ A4i r f , 

eff(m, T) = T , tfd(m, T) = B . 



10 Program Synthesis 

In order to establish a connection between collections of instruction sequence 
fragments and instruction sequences, we show in this section that, for each pos- 
sible joint behaviour of a collection of instruction sequence fragments, a single 
instruction sequence can be synthesized from the collection that produces on 
execution essentially the behaviour in question by making use of an instruction 
register file service. More precisely, we show that, for each PGA p program P 
and polyadic instruction sequence vector a, a PGA program P' can be synthe- 
sized from P and a such that, for all relevant instruction register file states a, 
\P'\ luiTUTa coincides with |P| CT (a) after the presence of the internal actions 
tau and gl has been concealed. 

Let P be a PGA p program and a be a polyadic instruction sequence vector. 
The general idea is that: 

— each polyadic instruction sequence in a is translated into a PGA P program 
and an appropriate finite collection of instances of this PGA P program in 
which occurrences of get instructions are replaced by core primitive instruc- 
tions is generated; 

— P and all the generated programs are translated into PGLC p programs and 
these PGLC p programs are concatenated; 

— the resulting PGLC P program is translated into a PGLD p program and this 
program is translated into a PGLD program by replacing all occurrences of 
the supplementary instructions by core primitive instructions as follows: 

• a switch-over instruction is replaced by an absolute jump instruc- 

tion whose effect is a jump to the beginning of an appended instruction 
sequence whose execution leads, after the state of the instruction register 
file has been found by a linear search, to a jump to the beginning of the 

5 We use the following notation for functions: [] for the empty function; [d 1— > r] for 
the function / with dom(/) = {d} such that f(d) — r; and / © g for the function 
h with dom(ft) = dom(/) U dom(gi) such that, for all d € dom(/i), h(d) = /(d) if 
d £ dom(gi) and h(d) = g(d) otherwise. 
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right instance of the PGA p program that corresponds to the ith polyadic 
instruction sequence in a; 

• a put instruction $put:i:w is simply replaced by the plain basic instruction 
irf.put:i:u; 

• a get instruction $get:z is simply replaced by the absolute jump instruc- 
tion whose effect is a jump to the position of the instruction itself. 

A collection of instances of the PGA p program corresponding to a polyadic 
instruction sequence in a is considered appropriate if it includes all instances 
that may become the one being executed. P and all the generated programs are 
translated into PGLC P programs because PGLC P programs are relocatable: they 
can be concatenated without disturbing the meaning of jump instructions. The 
PGLC p program resulting from the concatenation is translated into a PGLD p 
program before the supplementary instructions are replaced because the replace- 
ment of a switch-over instruction by an absolute jump instruction is simpler than 
its replacement by a relative jump instruction. 

Following the general idea outlined above, we define a function pgap2pgld 
that yields, for each PGA p program P, a function that gives, for each polyadic 
instruction sequence vector a, a PGLD program P' such that, for each relevant 
instruction register file service state a, pgld2pga(P')| /\^ITiT a coincides with 
|P| CT (a) after the presence of the internal actions tau and gl has been concealed. 

The function pgap2pgld from the set of all PGA p programs to the set all 
functions from the set of all polyadic instruction sequence vectors to the set of 
all PGLD programs is defined as follows: 

Pgap2pgld(x)(a) = 

translate (pglc2pgld( expand (x) (a) ) ) ; 
+irf.eq:l ; ##Z M ; . . . ; +irf.eq:n' ; ##Zi,„' ; 

+irf.eq:l ; ##Z„,i ; . . . ; +irf.eq:n' ; ##/„,„' , 

where n = len(a), n' = max(rng(#)), the function expand from the set of all 
PGA p programs to the set all functions from the set of all polyadic instruction 
sequence vectors to the set of all PGLCp programs is defined as follows: 

expand (x) (a) — 
pga2pglc(x) ; 

pga2pglc( 5 en(a, 1, -1 (l))) ; . . . ; pga2pglc( 5 en(a, 1, _1 (n'))) ; 

Pga2pglc(gen(a,n,6^ 1 (l))) ; . . . ; pga2pglc((/en(a, n, _1 (n'))) , 

where n = len(a), n' = max(rng(0)), and the function gen from the set 
of all polyadic instruction sequence vectors, the set of all natural numbers 
and the set of all instruction register file states to the set of all PGA p 
programs is defined as follows: 
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gen(a,i,a) = prj pgn(al) (pg(a,i))[a] if 1 < i < len(a) A valid(a,i,a) , 
gen(a, i, a) = #0 if 1 < i < len(a) A ^valid(a, i, <r) , 

gen(a, i,<r) = ! if i = V i > len(a) , 

the function translate from the set of all PGLD p programs to the set of all PGLD 
programs is defined as follows: 

translate(u! ;...;u k ) = V'i(wi) V>i(«fc) , 

where the functions tpj from the set of all primitive instructions of PGLD p 
to the set of all primitive instructions of PGLD are defined as follows 
(l<J<k): 

ipj (###<) =##/< if 1 < i < len(a) , 
^ = ! if i = V i > len(a) , 

^ij($put:i:u) = irf.put:z:u , 
^•($get:i) =##j, 

V'j(u) = it if u is not a supplementary basic instruction , 

where for each i G [1, len(a)]: 

h = len(pga2pglc(a;)) 

+ 1 en(pga2pglc( TOp9n(Q ^ ) ( ra (a,/i))[0- 1 (/i')])) 

he[l,lcn(a)],/i'erng(6>) 

+ 2 • max(rng(6<)) • (i - 1) , 

and for each i e [l,len(a)] and j G rng(6*): 

lij = lcn(pga2pglc(:r)) 

+ lcn (pga2pglc(TO ps „ (Q ^ ) (p. 9 ( a ^))[0- 1 (^)])) 

h€[l,i-l],/i'€rng(e) 

+ len (PS^PE^<Prj pgn{a! i ) {P9{a,i))[e- 1 (h')})) . 

h'e[i,j-i] 

The following theorem states rigorously that, for any PGA p program P and 
polyadic instruction sequence vector a, for all relevant instruction register file 
states a, |pgld2pga(pgap2pgld(P)(a))| j\^TR,T a coincides with |P| CT (a) after 
the presence of the internal actions tau and gl has been concealed. 

Theorem 1. Let P be a PGA p program and a be a polyadic instruction sequence 
vector, and let n be the highest number occurring in instructions of the form 
$put:i:u or $get:z in P or a. Take the interval [1, n] for I and the set of all core 
primitive instructions occurring in instructions of the form $put:i:u in P or a 
for U, and let a e IRFS. Then T tau (|pgld2pga(pgap2pgld(P)(a:))| / irf mP CT ) = 
rtau(r g i(|PU(a))). 
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Proof. The proof of Theorem 1 follows the same line as the proof of Theorem 1 
from [5] given in that paper. Here, we give only a brief outline of the proof of 
the current theorem. 

The proof of this theorem proceeds as follows: (i) we give a set T of closed 
terms of sort T with Tt au (T g \(\P\ a (a))) G T, a set T" of closed terms of sort T with 
T tau (|pgld2pga(pgap2pgld(P)(a))| / kf IKT a ) G T', and a bijection : T T'; 
(ii) we show that there exists a set E consisting of one derivable equation p = p' 
for each p G T such that, for all equations p — p' in E: 

— P(p) = p" is a derivable equation if p" is p' with, for all q G T, all occurrences 
of g in replaced by (3{q); 

— p' G T only if p' can be rewritten to a q' $ T using the equations in E from 
left to right. 

This means that T t3U (T gl (\P\ a (a))) and T tau (|pgld2pga(pgap2pgld(P)(a!))| / irf 
TRJ- a ) denote solutions of the same guarded recursive specification. Because 
guarded recursive specifications have unique solutions, it follows immediately 
that T tau (|pgld2pga(pgap2pgld(P)(a))| / irf !TZT a ) = r tau (r gi (\P\ a (a))). □ 

In the proof outlined above, an apposite indexing of the closed terms in the 
sets T and T' facilitates the definition of the bijection (3. Yet, this definition is 
much more complicated than the definition of the bijection needed in the proof 
from [5] referred to. 

The definition of pgap2pgld shows that the synthesis of single instruction se- 
quences from collections of instruction sequence fragments is fairly complicated. 

11 Conclusions 

We have given a formalization of a simple mechanism by which several instruc- 
tion sequence fragments can produce a joint behaviour. Thread extraction pro- 
vides the possible joint behaviours of a collection of instruction sequence frag- 
ments. We have shown that, for each possible joint behaviour of a collection 
of instruction sequence fragments, a single instruction sequence can be synthe- 
sized from the collection that produces on execution essentially the behaviour in 
question by making use of a service. This program synthesis is reminiscent of the 
service-based variant of projection semantics for program notations used in [6]. 
The program synthesis shows that it is a non-trivial matter to explain by means 
of a translation into a single instruction sequence what takes place on execution 
of a collection of instruction sequence fragments. 

In this paper, an instruction sequence fragment in a collection of instruction 
sequence fragments has two attributes: an ordinal index (position) and a program 
notation index. We have also mentioned that a nominal index (label) could be 
an optional attribute. Many other attributes that are relevant in practice can be 
imagined, e.g. modification date, author, tester, owner, user, and security level. 
In this paper, we have restricted ourselves to attributes that are indispensable 
for a theoretical understanding. 
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The question arises whether all aspects of the mechanism formalized in this 
paper can be dealt with at the level of threads. This issue has been investigated 
in [9] . It happens that not all aspects can be dealt with at the level of threads. In 
particular, the ability to replace special instructions in an instruction sequence 
fragment by different ordinary instructions every time execution is switched over 
to that fragment cannot be dealt with at the level of threads. Threads turn out 
to be too abstract to deal with the mechanism in full. 

It is sometimes suggested that program algebra is closely related to Kleene 
algebra [13] and omega algebra [12] - an extension of Kleene algebra with an 
infinite iteration operator. In program algebra, programs are considered at a 
more concrete level than in Kleene algebra and omega algebra. For instance, 
Kleene algebra and omega algebra are not concerned with instruction sequences, 
and program algebra is not concerned with non-determinism. 
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